create_application_commands can now take any IntoIterator: not just &[] #298
Conversation
|
This is a breaking change, therefore needs to be targeted at the |
zkxs
force-pushed
the
create_application_commands_IntoIterator
branch
2 times, most recently
from
60f2a85
to
28b9b64
Compare
zkxs
force-pushed
the
create_application_commands_IntoIterator
branch
from
28b9b64
to
b45fe30
Compare
|
@GnomedDev after some confusion between the |
|
Do you want to also update the functions that call create_application_commands to take advantage of the more permissive function signature? |
|
Sure; it should be done now unless I missed any: it looks like it's just |
|
Ignore the clippy issues, they are failing for unrelated issues, while you fix the |
|
@GnomedDev Should be done. I'm not checking the upper bound on size_hint, but that seems correct to me because in my experience overestimating the allocation tends to hurt performance more than underestimating. |
This is a small change: currently
poise::builtins::create_application_commandstakes a&[crate::Command<U, E>]. This PR changes it to take anIntoIterator<Item=&crate::Command<U, E>>. This doesn't really change much, except it makes the API slightly easier to work with if API users don't simply have aVec<Command<U, E>lying around: for example if you're dynamically computing which commands should be set on a guild-by-guild basis.